IBIS Macromodel Task Group Meeting date: 10 June 2014 Members (asterisk for those attending): Agilent: * Fangyi Rao * Radek Biernacki Altera: * David Banas ANSYS: * Dan Dvorscak * Curtis Clark Avago (LSI) Xingdong Dai Cadence Design Systems: * Ambrish Varma * Brad Brim * Kumar Keshavan * Ken Willis Ericsson: Anders Ekholm Intel: Michael Mirmak Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Micron Technology: Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy SiSoft: * Walter Katz * Todd Westerhoff Mike LaBonte Teraspeed Consulting Group: Scott McMorrow * Bob Ross The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - Arpad - Could we get a short summary of last week's Open Forum Summit. - Were IC vendors present to give feedback? - Could someone give a summary with that emphasis? - [Bob Ross, Brad Brim, and Walter Katz attended the Summit]. -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - None ------------- New Discussion: BIRD 147 Back-channel: - Brad - Bob, want to give a summary? - Arpad - Yes, nice to get an independent summary? - Bob - Brad Brim presented "Back Channel Crossroads" - Overview of BIRD 147. - Relies on BCI file, which is used by Tx and Rx models and AMI files. - Potentially controlled by standards committees (SAS, Fibre Channel ...) - Using IBIS proposed syntax they produce the BCI protocol files. - SiSoft proposal describes co-optimization of SERDES channels using AMI. - No BCI file. - Protocol agnostic. - Info stored in Tx or Rx AMI file. - Arpad - Were there any IC vendors there? Did we get any feedback from them? - Bob - There was some discussion. - David Banas from Altera and Xingdong Dai from Avago (LSI) were there. - David Banas - [just joining the call at that time...] - I'll repeat what I said during the discussion. - If there is a way that my existing Tx .dlls can be used in co-optimization without changing the code, then that's a big plus for me. - Arpad - Meaning use models that weren't designed for it originally? - Ken - If you're going to pre-define what the Rx can send back... - The Tx will have to accept it. - Walter - The Tx publishes its tap configuration to the EDA tool. - There are typically two ways to describe the taps. - Tx publishes the way they are described. - The Rx can determine what the optimal Tx equalization is. - Tell it to the EDA tool. - EDA tool translates that into how the Tx is reconfigured. - For example, it could call AMI_Close() and then re-call AMI_Init(). - Rx just has to say what tap coefficients it wants Tx to use. - EDA tool can convert to the Tx's published way of configuring them. - Arpad - Before we get into a technical discussion... - I want to summarize the current situation. - How are we going to continue? - It sounds like the summit didn't give us too much new info. - We did get David's preferences. - How do we decide what to do now? - Walter - Did Michael Mirmak indicate how he was going to vote today? - Arpad - Yes, it was not new information. - I'm not sure we had planned to have a vote today? - Walter - I'm okay with deferring until next week. - Teraspeed, ANSYS, Altera and Mentor abstained last time. - Would they like to rehear the proposals from the summit? - Arpad - We are familiar with them. Let's try a different approach. - What are the complaints from the two parties about each others' proposals? - For example, David's point. - Just wondering if we can combine them into one super-proposal? - Ken - I have two items. - BCI would involve interaction with standards bodies. - Need to figure out protocol specific content. - The same interaction would been needed if info is in Rx AMI file instead. - Reuse of existing models is enticing. Can you clarify it? - If you're lucky enough to have already coded your existing Tx models the right way then you have a shot. - We have seen lots of models from different people that may not be so lucky and use that exact format. They don't get the benefit? - David - Maybe it bears some ferreting out. - I'm not sure myself how restrictive it might be. - Ken - Even an existing model would need some function to publish data to Rx. - David - Walter's proposal just adds parameters to reserved AMI sections. - Walter - Synopsis thought having protocol agnostic Txs would be helpful. - There are two fundamental ways to specify Tx configuration. - Every Tx I know of has pre, main, and post cursor taps. - Maybe one or more than one pre or post. - The second issue is how does the AMI Model accept them? - Floating values from -1 to +1, or, - Integer values over some range (index). - Which is the parameter in the AMI file that represents each tap? - What I'm proposing are reserved AMI parameters that: - Communicate which are coefficient taps and which are indexed taps. - Define the min, max, and resolution. - Some vendors have a parameter for each tap, some don't. - Some expose the main tap, some don't. - There are various configurations. - They generally fall into one of several classifications. - Just define these several classes and cover 90% of cases. - We specify a way to do it. - It would be a straightforward change for those that don't already comply. - Ken - AMI model specific parameters were supposed to be a black box. - Now we're going to say you may have to redo it if you didn't do it this way? - Walter - We're not changing the model specific way for 90% of the models. - Ambrish - We are now talking about adding multiple reserved parameters. - One describes the range of coefficients. - What if I want to provide a dynamic range where I gradually dial it back? - Walter - Real world Silicon... - Every Tx I know of allows tap coefficients to be set with some granularity. - Ambrish - Real world Silicon would never do "statistical" flow. - If, in the future, an IP vendor asks me, "How can I transmit a dynamic resolution to my Rx (depending on my power usage)?" How do I do it? - Walter - In that case, there is a desire for a private protocol. - Private protocol that does all of these exotic things is possible. - New reserved parameter in my proposal. - Called "Rx_Tx_Communication" (for example). - Whatever comes out of Rx GetWave() is passed to Tx and vice-versa. - Equivalent to your protocol specific section. - Protocol specific stuff doesn't really have to be in a BCI file. - But all of this would require recompilation of the .dll. - We're saying there's a lot you can do with any need for recompiling. - Ambrish - How does the Rx understand what the Tx is sending and vice-versa? - Walter - They agree on the protocol. - Ambrish - That's not enough. - Walter - Isn't the protocol what's defined in the BCI file? - What are the protocol specific parameters of the BCI file? - Ambrish - They are what the Tx and Rx can talk about. - They can define other information to send each other. - Walter - Isn't that limited to the protocol specific section of the BCI file? - I'm saying we can have a simple Tx and Rx that use the private protocol. - The protocol is defined in other documentation. - Just a reserved AMI parameter in Tx and Rx that says what they're using. - Ambrish - Tx and Rx don't know how to communicate in that case. - Who would decide what gets passed between them? - Walter - Who decides what is in the BCI file? - I think Brad said, "IBIS should not be in the business of BCI files." - Brad - What I said is: - Just like an IBIS buffer, IBIS should define the format of the BCI file. - The content of an IBIS buffer or BCI file is up to the person defining it. - Existing protocols may not want to be bothered making the BCI file. - If they can't be bothered, IBIS should do it. - It's a paragraph, it's not rocket science. - I don't think we should be making standards out of others' standards. - Walter - So there is no approval process for BCI files? - Brad - If we publish it as an example it has to be approved. - Walter - Is it part of a BIRD? - Brad - It's the same thing for either alternative. - Walter - Who decides what it will be for 802.3bj? - Brad - That standards committee. - Walter - What if they don't? - Brad - You go and look it up. - Kumar - We have to approve both, so it's not a distinguishing point. - Ambrish - If the standards committee wants to make their own, IBIS doesn't do it for them. - Walter - Have you gone to the 802.3 committee? - Ambrish - No. - Walter - I have, and they don't want any part of simulation. - Ambrish - IBIS committee will do that if and when needed. - We'll have a standard BCI so the guy using it doesn't have to figure it out. - No assumptions and no confusion. - Only con is that every six months we need to meet and approve a BCI file. - David - These two proposals sound very different. - Why are we forcing one or the other? - Ambrish - Because back channel is what it's all about. - David - No, it's about co-optimization. Back channel is one solution. - Why can't we talk about Walter's scheme to get dumb old models to do co-optimization? - Ambrish - We've been talking about back channel for years. - Now this co-optimization solution comes along. - We are talking about standard back channel communication people have wanted. - Todd - Why don't we go with Walter's... - Ambrish - Simple question is still, do we want back channel or not? - Do we want to go toward general co-optimization or not? - It's one and that same. - Todd - Committee 101 says vote yes or no. - Arpad - Someone said BIRD 147 is a subset of co-optimization. Is that true? - Walter - Yes, I believe BIRD 147 is a subset of what I'm proposing. - Our customers are adamant that they don't care how it gets optimized. - They just want to find the optimal solution. - I can understand why it's useful to see "how." - Our community typically has 20 channels with different vendors. - They want optimization now. - Kumar - That is a red-herring. - There's no way to do it with an Init() only solution. - Ambrish - You say your customers will only benefit from your solution. - That's not true. We have statistical flow in our proposal. - Walter - I'm not saying yours is wrong. - Walter - Huawei has a back channel solution. - When they train it at low temp it doesn't work at high temp. - When they train it at high temp it works. - They have to do it via simulation and load the results. - Kumar - At the same DesignCon a Xilinx paper showed that it worked. - There's no way an Init() only solution can do it. - Walter - I've demonstrated that to a false statement. - It can be done in the Init() function. - Arpad - Let's let Todd talk... - Todd - This is a comment I made months ago that wasn't well received. - Co-optimization is simultaneously adjusting Tx and Rx for margin. - Whether back channel or anything else, it's optimizing for system margin. - I said to Kumar months ago, "you're trying to do it literally." - We have customers with 100s of channels who have to do the optimization ahead of time in simulation. - Ambrish - Are we trying to make an accurate model? - Or, are we trying to help the system level guy who is using the model? - Todd - I'm trying to make tools... - Ambrish - No, we are not doing tools. - Walter - Let me answer. - What you're proposing is a tool for the IC or IP vendor to develop or verify their model. - What I think IBIS should be doing is giving a tool for users to be able to co-optimize their channel. - If you look at what we agreed in 2007, main goal is to optimize the channel. - You're now proposing something to help design the IP. - Ambrish - What is the problem we are trying to solve? - Ken - I thought it was modeling. - Kumar - Rx has a VGA and CTLE, each of which has hundreds of settings. - Tx settings will depend on what VGA and CTLE settle to. - That's how it really happens to make an accurate model. - Arpad - If I want to attempt to answer Ambrish's question... - It depends on what we are trying to resolve. - If we're Intel we want alloys and crystal structures. That's a model. - Next level up is a transistor level model. - The first is for process engineers. - The second is for chip designers. - I think our context here is more system level. - Don't care about crystal or transistor level. Higher and Higher level. - Latest is AMI, we even got away from I/V curves. - Different level of abstraction. - Kumar - This is not about abstraction. - It's very path dependent and real devices have path dependent optimization. - It's a question of real optimization. - Arpad - I encourage people to keep working on this. - Lets work to try and make a decision for next week. - Ambrish - Kumar and I can't make it the next two weeks. - Arpad - Will someone from Cadence be here? - Brad - I can be here. - Arpad - We're at the top of the hour. ------------- Next meeting: 17 Jun 2014 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives